Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-159.txt

Text File | 1994-12-08 | 43.3 KB | 1,128 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 03 Aug 92       Volume 1 : Issue 159

Today's Topics:

    How to handle pdoc events - to quit or not to quit
    Changing addressing mode without rebooting
    The Answer to "Re: Serial output hangs"
    Backgrounding Question?
    _Delay should be banned
    'vers' resource conventions
    Info on the Twain API available ?
    Dialog Manager *too* 32-bit clean (was Re: Modal Dialog horrors and cdev's)
    Does the threads library work with THINK C?
    Patching PRGlue
    QuickDraw and animating PICTs (was re: XWindows)
    Trap dereferencing considered harmful? (was: Drawing with the mouse)



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Rainer Fuchs)
Subject: How to handle pdoc events - to quit or not to quit
Date: 26 Jun 92 12:32:17 GMT
Organization: EMBL Data Library

I have a question about the reaction to a pdoc AppleEvent:

A user can select a number of documents from the Finder and
select Print. The Finder launches the application and sends a
pdoc AppleEvent. What should the application do after processing
the AppleEvent? Should it quit or not? The same question applies
of course for System 6 and MultiFinder, where AppleEvents are
not used.

I couldn't find any clear information about this issue. Looking at
what other people do, I found a couple of programs that quit after
printing, but also many that don't.

Rainer Fuchs
EMBL Data Library
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Sat, 27 Jun 92 18:27:23 GMT

In article <[e-mail]> [e-mail] (Rainer Fuchs) writes:
>I have a question about the reaction to a pdoc AppleEvent:
>
>A user can select a number of documents from the Finder and
>select Print. The Finder launches the application and sends a
>pdoc AppleEvent. What should the application do after processing
>the AppleEvent? Should it quit or not? The same question applies
>of course for System 6 and MultiFinder, where AppleEvents are
>not used.
>
    It has always been the rule that you should QUIT after getting
told by the user to print.  This has been true since the beginning of the Mac
(MacPaint & MacWrite did it!) and is still true today when recieving pdoc
events.
    There are some application that don't do this, they're wrong!!

- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Sat, 27 Jun 1992 21:09:33 GMT

In article <[e-mail]> [e-mail] writes:
>>
>    It has always been the rule that you should QUIT after getting
>told by the user to print.  This has been true since the beginning of the Mac
>(MacPaint & MacWrite did it!) and is still true today when recieving pdoc
>events.
>    There are some application that don't do this, they're wrong!!

    One must make allowances for changing times. Under System 7,
it's possible to get a 'pdoc' event while the program is already running
(i.e. after having received an 'oapp', and not at startup time). In this
case, it's desirable not to quit after servicing the 'pdoc' event.

R.

- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Sun, 28 Jun 92 04:05:34 GMT

In article <[e-mail]> [e-mail] (Rich Siegel) writes:
>In article <[e-mail]> [e-mail] writes:
>>>
>>    It has always been the rule that you should QUIT after getting
>>told by the user to print.  This has been true since the beginning of the Mac
>>(MacPaint & MacWrite did it!) and is still true today when recieving pdoc
>>events.
>>    There are some application that don't do this, they're wrong!!
>
>    One must make allowances for changing times. Under System 7,
>it's possible to get a 'pdoc' event while the program is already running
>(i.e. after having received an 'oapp', and not at startup time). In this
>case, it's desirable not to quit after servicing the 'pdoc' event.
>
    That's true, Rich, but the discussion was what to do when you get it
at Application launch time.  Obvoiusly, if you've already been running and
you THEN get a pdoc, you don't want to quit!

Leonard

- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 30 Jun 92 18:23:05 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] writes:
>    That's true, Rich, but the discussion was what to do when you get it
>at Application launch time.  Obvoiusly, if you've already been running and
>you THEN get a pdoc, you don't want to quit!

No, a 'pdoc' means print, not quit, even at launch time.  Pasted below is
a Q&A which discusses the issue.

Grobbins            [e-mail]

Usual disclaimers apply.

- ---


from the Q&A Stack:

Toolbox & IAC:Apple Events:4/17/92
LaunchApplication and event sequence

Is it the case that if I double-click on a document belonging to
my application, my application will be launched and will receive
an 'odoc' Apple event, but will not receive an 'oapp' event-that
is to say, I will receive either 'odoc' or 'oapp', but not both?


You are correct, except actually, it'll be either 'oapp' or 'odoc'
or 'pdoc'. The 'pdoc' will be followed (as the next event) by a
'quit' if the 'pdoc' was the event sent as the application was
launched.

This is the *normal* sequence of events, and should be adhered to
by everyone who launches applications. However, it is not
*enforced* by the system or Finder. It is possible for any
application to launch you with *any* event, since they can stuff
anything in the launchAppParameters field of LaunchApplication, as
long as it's a valid high-level (not even Apple) event. This would
be bad programming, and would break most launched applications,
but you should be aware that someone who hasn't understood things
may do this to you.

Note that if another application launches you using
LaunchApplication and doesn't specify any high-level event in the
launch parameter block, the Finder will automatically supply the
'oapp'. So, in general, in the correct way to code Apple events
and launching, you will always get an 'oapp' XOR an 'odoc' XOR a
'pdoc'.




---------------------------

From: [e-mail] (Michael Kelly)
Subject: Changing addressing mode without rebooting
Date: 27 Jun 92 21:50:23 GMT
Organization: Apple Computer Inc., Cupertino, CA


I've been using a Mac with a lot of memory the last few months, and so I need
the machine to be in 32-bit addressing mode most of the time so that I can get
to my memory.  Unfortunately, there are several programs that I like to use
that are not 32-bit compatible (Word 4, e.g.).  When I want to use those
programs, I have to turn 32-bit addressing off and restart.  I'm getting
pretty fed up with having to do that.

Is it possible at all to switch the addressing mode without rebooting?  If it
is, someone should write a control panel, similar to SpeedSwitch '040 in
design, that would allow the user to turn 32-bit addressing on and off without
rebooting.  Surely it must be possible, although I suspect it would be
extremely difficult.

Does something like that already exist?

BTW, does anyone know of anything that will switch the cache setting on a
Quadra automatically for each program?

Thanks,

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                         Apple Computer, Inc.
[e-mail]                 Advanced Technology Group, Graphics Software
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 27 Jun 92 23:08:53 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Michael Kelly) writes:
>
> I've been using a Mac with a lot of memory the last few months, and so I need
> the machine to be in 32-bit addressing mode most of the time so that I can get
> to my memory.  Unfortunately, there are several programs that I like to use
> that are not 32-bit compatible (Word 4, e.g.).  When I want to use those
> programs, I have to turn 32-bit addressing off and restart.  I'm getting
> pretty fed up with having to do that.
>
> Is it possible at all to switch the addressing mode without rebooting?  If it
> is, someone should write a control panel, similar to SpeedSwitch '040 in
> design, that would allow the user to turn 32-bit addressing on and off without
> rebooting.  Surely it must be possible, although I suspect it would be
> extremely difficult.
>
> Does something like that already exist?

I don't think that something like what you describe exists, or ever will exist.
You are probably correct that it is possible, but as Jim Reekes would put it, it
would be "way hard." Not only would you have to hunt down every block allocated
by the Memory Manager and convert it from 24/32 bit format to 32/24 bit format
(this is the hardest part), but you'd also have to figure out which toolbox
managers change their internal storage formats based on what mode the Mac is in
(e.g., Window Manager, Control Manager) and change that data to the appropriate
new format. This, too, is the hardest part. I figure that it would take someone
who was already intimately familiar with all those parts of the system many
months to come up with such a utility.

If I were you, I'd just get programs that worked under 32-bit mode. Companies
that take the time to update their software for 32-bit mode, or who are
conscientious enough to write their programs to be 32-bit compatible in the
first place are the kinds of companies I like to support.

Word 5 is 32-bit compatible, as well as works on '040 Macs. I'm sure the Apple
Engineering Library has it on their KeyServer.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Jon Howell)
Subject: The Answer to "Re: Serial output hangs"
Date: 28 Jun 92 00:05:40 GMT
Organization: Tektronix, Inc., Wilsonville,  OR.

From: [e-mail] (David P. Alverson)
>>    I'm getting started trying to write some data out the serial port.
>>I don't have my code with me (it's as home), but it goes something like
>>this (with error checking): [gross generalizations here]
>>
>>    OpenDriver(&refNum, ".AOut");
>>    SerReset(refNum, baud1200+data8+stop20+parityNone);
>>    FSWrite(refNum, strlen(mystring), mystring);
>>
>>When I plugged the cable into my modem, the debugging messages tell me I've
>>made it all the way to the FSWrite, at which point it locks up. (I have to
>
>I would say its probably waiting for the CTS line.  Look at the SerHShake
>call; you want to set fCTS and fDTR to zero in the SerShk record.

Thanks, Dave -- you were right on the money. I went home and tried this out
(I even forgot fDTR [which left it non-zero]), and it worked fine. Thanks
for taking the time to help me out.

I've included my modem init routine (after which I call the SerialSend routine
I found in terminal.c, available from sumex-aim.stanford.edu /info-mac/source),
because this will also be posted to c.s.m.p for other poor slobs of my
small caliber. :v)

At any rate, it runs. Thanks!

    -- Jon

- ----snip snip----
#include <Serial.h>

short    int sm_refOut, sm_refIn;
Boolean    sm_sendBusy;

void serModemInit(void)
{
    SerShk flags;

    /*** Open output and input drivers ***/
        if (OpenDriver("\p.AOut", &sm_refOut))
        {    sm_refIn=sm_refOut=0;    return;    }

        if (OpenDriver("\p.AIn", &sm_refIn))
        {    sm_refIn=sm_refOut=0;    return;    }

    /*** Set up communications paramaters ***/
        if (SerReset(sm_refOut, baud1200+stop10+noParity+data8))
        {    sm_refIn=sm_refOut=0;    return;    }

        if (SerReset(sm_refIn, baud1200+stop10+noParity+data8))
        {    sm_refIn=sm_refOut=0;    return;    }

    /*** Set up handshaking ***/
        flags.fXOn = TRUE;
        flags.fCTS = FALSE;
        flags.xOn  = '\021';
        flags.xOff = '\023';
        flags.errs = 0;
        flags.evts = 0;
        flags.fInX = TRUE;
        flags.fDTR = TRUE;

        if (SerHShake(sm_refOut, &flags))
        {    sm_refIn=sm_refOut=0;    return;    }

        if (SerHShake(sm_refIn, &flags))
        {    sm_refIn=sm_refOut=0;    return;    }

    /*** Clear busy flag so we're clear to transmit ***/
    sm_sendBusy = FALSE;

    /* If we made it this far, the ports are ready to roll */
}

/* ----- Send buffer --------------------------------------------------- */
/* taken from terminal.c, available on sumex-aim.stanford.edu under     */
/* /info-mac/source (I think).                         */

#define OUTPUT sm_refOut

static pascal void SendComplete(void)
{
    /* A0 has address of IOParam */
    asm {
        MOVE.L    -4(A0),A0    /* Get busy flag address */
        CLR.B    0(A0)        /* Clear the busy flag (FALSE) */
    }
}

void SerialSend(
    register char *buffer,
    register long count,
    register Boolean *busy)
{
    static struct {        /* Must be static! */
        Boolean *busy;    /* TRUE while sending */
        IOParam b;
    } param;

    if (!OUTPUT) {
        *busy = FALSE;
        return;
    }
    *busy = TRUE;
    param.busy = busy;
    param.b.ioCompletion = (ProcPtr)SendComplete;
    param.b.ioRefNum = OUTPUT;
    param.b.ioBuffer = (Ptr)buffer;
    param.b.ioReqCount = count;
    PBWrite((ParmBlkPtr)¶m.b, TRUE);        /* Asynchrone */
}
- --
Jon Howell [e-mail] | 503/657-7964h 503/685-3048ofc | What good is
    having someone who can walk on water if you don't follow in his footsteps?

---------------------------

From: [e-mail] (J Eric Bush)
Subject: Backgrounding Question?
Organization: The Ohio State University
Date: Mon, 29 Jun 1992 01:09:10 GMT

Does anyone know of a way to make an application (or force an application) into
the background?  I know that when the MouseClick is placed in another
application, the current application is sent to the background under System 7.
But, can you force an application to the background, or return to the Finder
without quitting the application?

Please send replies to: [e-mail]

If anyone is interested in the answer, send mail, and I will send you whatever
is sent to me.

Thanks in advance.
Eric Bush
- --
- ------------------------------------------------------------------------------
J. Eric Bush
Internet: [e-mail]   ProLine: [e-mail]
GEnie:    KITCHEN.SINK

+++++++++++++++++++++++++++

From: Anders Wallgren <[e-mail]>
Organization: Verity, Inc., Mountain View, CA, USA
Date: Mon, 29 Jun 92 01:53:14 GMT

In article <[e-mail]> J Eric
Bush, [e-mail] writes:
>Does anyone know of a way to make an application (or force an
application) into
>the background?  I know that when the MouseClick is placed in
another
>application, the current application is sent to the background
under System 7.
>But, can you force an application to the background, or return to
the Finder
>without quitting the application?

Use SetFrontProcess() to force a process (other than the one you
want to background) into the foreground, thus sending this other
process to the background.  I don't know of any way to explicitly
put a process in the background.

anders

---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: _Delay should be banned
Date: 29 Jun 92 19:34:15 +1200
Organization: University of Waikato, Hamilton, New Zealand

Lately I've been having problems with a piece of commercial software which
shall remain nameless. This program tries periodically to open a file. When
it fails, because the file is already open for conflicting access by someone
else, it calls the OS Utilities "Delay" function to delay for 60 seconds, then
tries again.

Now, the implementation of Delay has not changed *one whit*, as far as I'm
aware, from its original 1984-vintage implementation. It sits in a tight,
CPU-bound loop until a specified number of ticks has elapsed. Now, this may
have been acceptable in pre-MultiFinder times, but these days, commission
of a Delay call is definitely an unfriendly act.

It's strange that I recall no mention of the use of Delay in conjunction with
MultiFinder-friendliness, in any of Apple's documentation or guidelines.
Basically, *don't* use it for any but the very shortest delays (a fraction
of a second is probably OK). At least try and let background tasks run while
you're waiting for whatever it is you're waiting for.

I suppose that the reason why Apple can't reimplement Delay to allow
background tasks to run is because you could then have memory movements
happening in the system heap (as a consequence of OS calls from background
tasks), which could break some programs. Sigh...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 29 Jun 92 11:29:15 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ac.nz> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

   I suppose that the reason why Apple can't reimplement Delay to allow
   background tasks to run is because you could then have memory movements
   happening in the system heap (as a consequence of OS calls from background
   tasks), which could break some programs. Sigh...

Not to mention that some apps draw in the WMgrPort, call Delay, and
then reset the port. If someone was to draw in between...

It's sad that the mac wasn't designed for preemption from the very
beginning. Now we will have to use a new API for the preemptively
multitasking kernel.

I'm talking A/UX, of course, what else did you think ? :-)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: 'vers' resource conventions
Date: 29 Jun 92 14:53:52 GMT
Organization: U of Wisconsin-Madison College of Engineering

I was just editing the 'vers' resource of my app in ResEdit 2.1.1, when I
realized something a little strange.  There are the three fields at the top,
x.y.z, which correspond to major revision, minor revision, and bug fix, or
something like that.  Then there's the release, Development, Alpha, Beta,
Final, which I assume correspond to the b in 1.2b3, etc.  But then, next to
that is a number field "non-release."  What, if any, are the conventions
regarding this field.  I realize the 'vers' resource is not exactly a carved-
in-stone standard, but there seem to be some reasonably well followed
conventions.  Where does non-release fit into these?

Not a world-shaking problem, just a nagging little curiosity. =:-)

Thanks,
Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Mon, 29 Jun 1992 15:40:16 GMT

[e-mail] (Jeffrey Verdegan) writes:

>I was just editing the 'vers' resource of my app in ResEdit 2.1.1, when I
>realized something a little strange.  There are the three fields at the top,
>x.y.z, which correspond to major revision, minor revision, and bug fix, or
>something like that.  Then there's the release, Development, Alpha, Beta,
>Final, which I assume correspond to the b in 1.2b3, etc.  But then, next to
>that is a number field "non-release."  What, if any, are the conventions
>regarding this field.  I realize the 'vers' resource is not exactly a carved-
>in-stone standard, but there seem to be some reasonably well followed
>conventions.  Where does non-release fit into these?

In something like "1.2b3", the "3" is the non-release version number.
"1.2b3" is actually "1.2.0b3". When writing it out in text, people
drop the bug-fix version number if it is equal to 0. The major release
number and the non-release number begin with 1, and the minor release
number and bug fix number begin with 0. So, my first alpha test
version of my second bug fix version of a program which was previously
at version 3.4 would be "3.4.2b1". Neat, huh?

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Coffee Junkie)
Date: 29 Jun 92 15:54:44 GMT
Organization: University of Illinois at Urbana

Pete Resnick writes
> So, my first alpha test
> version of my second bug fix version of a program which was previously
> at version 3.4 would be "3.4.2b1". Neat, huh?
                                ^
                                a.
- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Andy Peterman)
Date: 29 Jun 92 20:50:11 GMT
Organization: The Treehouse

In article <[e-mail]> [e-mail] (Je
ffrey Verdegan) writes:
>I was just editing the 'vers' resource of my app in ResEdit 2.1.1, when I
>realized something a little strange.  There are the three fields at the top,
>x.y.z, which correspond to major revision, minor revision, and bug fix, or
>something like that.  Then there's the release, Development, Alpha, Beta,
>Final, which I assume correspond to the b in 1.2b3, etc.  But then, next to
>that is a number field "non-release."  What, if any, are the conventions
>regarding this field.  I realize the 'vers' resource is not exactly a carved-
>in-stone standard, but there seem to be some reasonably well followed
>conventions.  Where does non-release fit into these?

The three fields of x.y.z refer to a version number like 1.2.3 where the 3 is
the bug fix field.  In a version like 1.2b3, the 3 is the "non-release" number.
There's actually four number fields, although the "non-release" field is never
shown for "release".  It's possible to have a version 1.2.3b4, which would be
the beta 4 version of bug fix 3 for minor revison 2 of major version 1 (whew!).

The 'vers' resources ARE carved-in-stone.  See Tech Note 189 or IM VI.  It's
actually a very nice system, especially because there's a 32 bit value that
corresponds to the version number that will always increase for newer versions.
- --
Andy Peterman
treehouse![e-mail]
[phone]

---------------------------

From: [e-mail] (Herb Schilling)
Subject: Info on the Twain API available ?
Organization: NASA Lewis Research Center
Date: Mon, 29 Jun 1992 16:06:19 GMT


Does anyone know where we can get information about the TWAIN API that is
being proposed ( and implemented, I guess )? It supposedly establishes
a device independent interface to input devices such as scanners. MacWeek
reports that Wordperfect will be using it.

Thanks in advance. I will summarize any responses I get.
- --
Herb Schilling , NASA Lewis Research Center , 21000 Brookpark Road, MS 142-5
Cleveland, Ohio 44135 . [phone]       [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Herb Schilling)
Date: 30 Jun 92 11:15:57 GMT
Organization: NASA Lewis Research Center

In article <[e-mail]> [e-mail] (Herb Schilling) writes:
>
>Does anyone know where we can get information about the TWAIN API that is
>being proposed ( and implemented, I guess )? It supposedly establishes
>a device independent interface to input devices such as scanners. MacWeek
>reports that Wordperfect will be using it.

I will answer my own question ! You can call 800-722-0379 to order a TWAIN
toolkit. If you have access to Compuserve, look in the HPPER libraries for
TWAIN.


- --
Herb Schilling , NASA Lewis Research Center , 21000 Brookpark Road, MS 142-5
Cleveland, Ohio 44135 . [phone]       [e-mail]

---------------------------

From: [e-mail] (Pete Resnick)
Subject: Dialog Manager *too* 32-bit clean (was Re: Modal Dialog horrors and cdev's)
Organization: University of Illinois at Urbana
Date: Tue, 30 Jun 1992 07:20:06 GMT

This was one of the most stressful debugging sessions I have ever had.
I thought I would post to let all of you know the solution because this
could bite anyone. For those who didn't see the initial post, I was
getting really screwy looking, half drawn dialog boxes and crashes from
a code resource I had written. Though I thank all those who sent
e-mail, I should tell you that the problem was not caused by THINK C's
A4 globals or by SetPort/GetPort mistakes.

The problem seems to be that the Dialog and/or Window Manager are not
being 24-bit friendly. I created my dialogs using the dStorage
parameter to NewDialog. The storage I used were DialogRecords I had
declared as global variables. The mistake that I made was that I made
calls to the Dialog and Window Manager routines using the address of
those structures rather than the address returned to me from the
NewDialog call. So, I was doing the following:

NewDialog(&myDRec, ....);
[...]
CloseDialog(&myDRec);

It turns out that if you do this, you *must* call StripAddress for all
subsequent calls: on a Mac SE, the top byte of that address you pass
to CloseDialog will be garbage and it is *that* that screws up the
Dialog Manager. My solution was to put the returned value from
NewDialog into another global and do the following:

myDPtr = NewDialog(&myDRec, ....);
[....]
CloseDialog(myDPtr);

That works fine. I don't know, but all this seems kinda icky of the
Dialog Manager to do.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Tue, 30 Jun 92 14:58:11 GMT
Organization: cellular

[e-mail] (Pete Resnick) writes:

>The problem seems to be that the Dialog and/or Window Manager are not
>being 24-bit friendly. I created my dialogs using the dStorage
>parameter to NewDialog. The storage I used were DialogRecords I had
>declared as global variables. The mistake that I made was that I made
>calls to the Dialog and Window Manager routines using the address of
>those structures rather than the address returned to me from the
>NewDialog call. So, I was doing the following:

>NewDialog(&myDRec, ....);
>[...]
>CloseDialog(&myDRec);

THINK C code resources address their globals relative to A4. But they
don't set up A4, as you know. You have to set it up yourself, throught
RememberA0 and SetUpA4 or something similar.

RememberA0, of course, gets the value it "remembers" from register A0.
And, on entry to your code resource, the THINK code resource glue has
put a pointer to the code resource in A0.

Here's the problem: the THINK code resource startup glue gets the value
of A0 via a 0 code offset. In other words, the glue knows the distance
between the instruction that sets up A0 and the first instruction in
the code resource and uses that. This is done via an offset from the
PC register. In a 24 bit system, the PC may well be 32-bit dirty,
because the system likely simply jumps to a master pointer it got
from the resource manager.

If the PC is 32-bit dirty, this dirtiness propagates all the way down
to A4, and as soon as you pass the address of a global variable to
somebody, it's not 32-bit clean. Ick.

You can clean this up with a short assembly language routine which
might look something like this:

static void CleanPC (void)
{
    asm
    {
        LEA @1,A0
        MOVE.L A0,D0
        _StripAddress
        MOVE.L D0,A0
        JMP (A0)
@1
    }
}

Try this out before you trust it; I just typed it out impromptu.

Anyway, the real question here is "Why does the dialog manager care
about a dirty upper byte when the SE couldn't use it even if it wanted to?"
- --
 Pete Gontier // EC Technology // [e-mail]

---------------------------

From: [e-mail] (Sho Kuwamoto)
Subject: Does the threads library work with THINK C?
Date: 30 Jun 92 07:50:24 GMT
Organization: Purdue University Physics Department

1) Does the threads library work under THINK C?
2) Is the threads library still available on the Develop CD?
3) How do I subscribe to Develop?

Thanks.

- -Sho
- --
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 30 Jun 92 18:24:32 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Sho Kuwamoto) writes:

>1) Does the threads library work under THINK C?

I had heard of someone using it with Think. I don't know what's involved. Since
you don't get the source, it can't be much trouble. It may have had to do
with pascal functions.

>2) Is the threads library still available on the Develop CD?

All the developer CDs have all back issues on them. The threads articles were
in develop 6 and 7, but a newer version was released in 8 (although it was in
the 6 folder!).

>3) How do I subscribe to Develop?

Try [e-mail]. Note, however, that all issues are on
ftp.apple.com in dts/mac/docs/develop.

>Thanks.
Enjoy.
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett

---------------------------

From: [e-mail] (Wade Williams)
Subject: Patching PRGlue
Organization: Auburn University
Date: Tue, 30 Jun 1992 13:17:58 GMT

OK, here's one I've been trying to solve for a while with no success:

I'm trying to write a patch to PRGlue that will password-protect printing
operations.  In reality, I might end up patching PROpenDoc or something like
that, but the principle is the same.

Because this patch needs to be active at all times, regardless of what
application is running, I've surmised that the best technique is probably for
my INIT to load a standalone CODE resource into memory, then patch PRGlue.
When someone tries to print, the PRGlue patch will jump them to my standalone
code, which displays a dialog prompting them for a password.

The problem is, if the user enters the correct password, we then need to jump
from the standalone code to the true PRGlue Trap address.  The problem is, how
can I pass that Trap address from the INIT which installs the trap to my
standalone code?

(Listening for the groans)

By the way, I don't know assembly, so you can't say "just push it on the stack"
or something similar.  (I know, I know, it's crazy for someone who doesn't
understand assembly to go around patching traps and writing INITs, but I'm the
best we've got - a depressing thought).  Also, the standalone code won't be
called until the first time someone tries to print, so it might be hours until
the standalone code has to actually fetch the original PRGlue Trap address.

And finally, if A4 is setup properly, can I use the Dialog Manager in my CODE
resource?

Thanks,
Wade

- -------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
- -------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 1 Jul 1992 12:34:20 GMT

"just push it on the stack"

Just kidding...look up NGetTrapAddress and NSetTrapAddress. Also, if you are
using THINK C I would recommend writing at least _some_ of the patch in asm.

Good luck.


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: QuickDraw and animating PICTs (was re: XWindows)
Organization: Kalamazoo College
Date: Mon, 29 Jun 1992 21:39:05 GMT

[e-mail] (Hugh Fisher) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>
>> I'm not sure what you mean by "serious hassles."  Lawrence hinted that X
>> doesn't support friendly, powerful sharing of a color table by multiple
>> windows, which the Palette Manager provides.  If true, perhaps that's
>> why offscreen images seem hard--the power doesn't come for free.
>> Actually, I don't know how offscreen images could have been done more
>> straightforwardly without sacrificing efficiency.
>
>  I wrote an article on this for MacTutor magazine after I had done
>  the color version of a Mac game (Fire Brigade). Briefly,
>
>  With the original palette manager, you couldn't store offscreen PICTs
>  with animating colors. The Palette Manager prevented 'ordinary' drawing
>  calls from getting at pixels reserved for animation. If you set up an
>  offscreen pixmap for use with animating colors and tried to draw a PICT
>  in it, the PICT came out in black and white. You couldn't draw it and
>  then set up the animation pixel values either, or at least not by following
>  the Mac API.

This relates to a question in a previous article, which I'll attempt to
answer before going on:

From: [e-mail] (william bradley ward)
Subject: Animating PICT colors
Date: 28 Jun 92 01:19:56 GMT

>Anybody have any idea how to animate the colors of a PICT, as I'm at
>a loss on how to do so?
>
>My problem is that I can animate "normal" colors that I draw manually
>(using LineTo, FrameCRect, etc) fine, but I am unable to animate those
>same exact colors when they are in a pre-saved PICT resource.
>
>I am using the same palette of colors, that the PICT uses, for the animation
>process.  For example, I displayed the PICT, picked a color from the PICT,
>and drew a line in that color in the same window.  I then animated that color
>(had it cycle through many shades of gray).  The line animated fine, but
>the same color in the PICT itself did not change.

The problem is that any color declared as pmAnimated won't be picked as
a match by any QuickDraw routines.  When you draw "manually" with them,
you're using PmForeColor() to tell the Palette Manager to tell QuickDraw
to set the drawing color directly.  But if you use RGBForeColor(),
QuickDraw will ask the Palette Manager to match the color, and the
Palette Manager will never return an animated color in that case.

Now, I don't know much about PICTs, but I don't see the PmXxxColor()
calls in the list of opcodes for pictures--which makes sense, they're
not QuickDraw calls.  Fortunately, there's an easy way around this, but
it requires 32-bit QuickDraw.  This is what Hugh is talking about up
there.

You need to first draw the picture into an offscreen pixmap.  Use the
PICT's clut for that pixmap.  Then you need to use a 32-bit QD feature
to get that onto the screen with the appropriate colors.  Specifically,
you need to set the "value" fields of the offscreen pixmap's color
table's entries to be the _palette_ entries of the window you're drawing
into.  If your PICT is 20 shades of green, you just need 20 pmAnimated
shades of green in the palette.  They don't have to match the clut;  if
the value field of color #3 is 200, then color #3 will be mapped onto
palette entry 200.

Then set bit 14 of the offscreen pixmap's color table's ctFlags field to
one, and call CopyBits().  This mapping-to-a-palette thing only works
for CopyBits, only when bit 14 is set, and only when you're drawing to a
window (because only windows can have palettes).

Back to Hugh:

>  This all got fixed with 32 bit Quickdraw and the new pmExplicit + colors,
>  which, sorry to labour the point, is much more like X Windows: there is
>  a nice, straightforward 1:1 mapping between stored pixel values and index
>  numbers in palettes/color tables.

Nope.  It's more flexible than that.  William, if you want to map all
twenty of the offscreen pixmap's colors onto three palette entries, you're
free to do so.  Also, being pmExplicit has nothing to do with it:  you
can copy into pmCourteous colors if you want.

pmExplicit colors allow speed freaks to control the color tables and
still go through the Palette Manager.  They're useful when you want to
write directly to the screen, which most animation/paint programs do
anyway--so not being able to go through the Toolbox is not nearly as bad
as it sounds.  And explicit colors have been in from day one.  My
Copyright 1988 IM V declares pmExplicit on page 167.

>  The
>  specification of an X Windows color table entry has three 16 bit
>  fields for red, green, and blue; and a 32 bit field for the actual
>  pixel value. The Mac format has the same fields but only 8 bits
>  for the pixel.

Sixteen, actually.  Not that it matters.  And, yes, things get
complicated when you start calling AnimatePalette(), I know.

>  It did cause some trouble. The first few 24 bit color displays from
>  Radius, etc had to patch the system software and had compatibility
>  problems.

Hm!  I didn't realize this--interesting.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Whenever I open the manuals for OOP, I have the strangest desire to find
  the nearest pillow and fall asleep."   - David Denboer

---------------------------

Subject: Trap dereferencing considered harmful? (was: Drawing with the mouse)
From: [e-mail] (Tim Hammett)
Date: Tue, 30 Jun 1992 22:22:12 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Reid Ellis) writes:
>Would the code benefit from GetTrapAddress() to avoid the toolbox trap
>mechanism?  Or does this have the unfortunate side effect of possibly
>deaccellerating and Quickdraw accellerators running?

Frequently people mention using GetTrapAddress() to get the address of a trap
so that they can then jump directly to the trap and thus avoid trap
dispatcher overhead. Although this seems to be a frequently used technique,
I wonder about the future compatibility of this trick. Some possible
concerns are:

1. If the application is running in the 680x0 user mode, and the trap
   being called does something that requires the processor to be in
   supervisor mode. In this case I'd assume that using the normal trap
   mechanism would put the processor in supervisor mode, while bypassing
   the normal trap mechanism would leave it in user mode.

2. If memory protection is implemented in the future (I know the system
   heap makes this difficult), and the trap routine writes to some
   memory area that is protected from being directly written by the
   application code (e.g. some I/O registers, or even the screen memory).
   Once again, bypassing the trap mechanism & jumping into the ROM
   directly might cause some problems.

So, am I being needlessly paranoid, or is bypassing the trap dispatcher
a potential cause of compatibility problems?

TIA,
    --- Tim.



- --
Tim Hammett, Botany Dept, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Wed, 1 Jul 1992 00:30:35 GMT

.ac.nz> [e-mail] (Tim Hammett) writes:

   Frequently people mention using GetTrapAddress() to get the address of a trap
   so that they can then jump directly to the trap and thus avoid trap
   dispatcher overhead. Although this seems to be a frequently used technique,
   I wonder about the future compatibility of this trick. Some possible
   concerns are:

This is a bad idea, generally.

   1. If the application is running in the 680x0 user mode, and the trap
      being called does something that requires the processor to be in
      supervisor mode. In this case I'd assume that using the normal trap
      mechanism would put the processor in supervisor mode, while bypassing
      the normal trap mechanism would leave it in user mode.

Presumably. This is important enough, but:

   2. If memory protection is implemented in the future (I know the system
      heap makes this difficult), and the trap routine writes to some
      memory area that is protected from being directly written by the
      application code (e.g. some I/O registers, or even the screen memory).
      Once again, bypassing the trap mechanism & jumping into the ROM
      directly might cause some problems.

Yes, and even more important: RISC !

RISC Macs will execute traps in "native" code, which is not directly
executable by the MC68kX emulator. Maybe Apple kludges up something
to fix this, but don't bet on it.

   So, am I being needlessly paranoid, or is bypassing the trap dispatcher
   a potential cause of compatibility problems?

Don't do it unless you can turn it off in the program (and it's
by default off)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

---------------------------

End of C.S.M.P. Digest
**********************